In all places where you return emptyList in this getNameSuggestions function, you should return generateNewClassNames(psiClass).

Otherwise, this solution doesn't map all valid inputs into a successful rename (although the previous solution without any memory would).

As discussed on Slack, since we use the memory as a way to make the transformations deterministic, returning an emptyList is the desired behavior.

Looking at these getNameSuggestions(psiComponent, memory), it's apparent that you can reduce it into a "cached-or-call-method" semantic:

[suspend] fun <R> Memory.cachedOrCall(signature: String?, callback: [suspend] () -> R): R {
    val memory = this
    if (signature != null && memory.has(signature)) return memory.getValue(signature)
    
    // otherwise, when missing, execute a callback
    val result = callback()
    if (signature != null) memory.store(signature, result)
    return result
}

// How To Use:
// inside your transformation
val methodSignature = readAction { SignatureGenerator.signatureOf(psiMethod) }

val suggestions = memory.cachedOrCall(methodSignature) {
    suggestNewMethodNamesByAI(/* whatever */)
}

return suggestions

This way, your memory can be used not only for renames, but for everything; which is needed by my PR as well.

Since we do not want the fallback to be an LLM call, this is not necessary, but i restructured the logic in 128b06d to split the two more clearly.

‼️ This hard-coded setup of memoryBaseDir makes the save location very rigid.

It should be a caller's responsibility to define where this memory instance saves its data.

I'd place this folder selection logic somewhere to the upper layer of the project (HeadlessStarter or ExecutionService), and make the memoryBaseDir a constructor parameter of a memory instance.

I'd make it optionally parameterizable from the CLI: Useful for the eval pipeline to decide where to store the memory (i.e., creating and parsing this filepath somewhere in the HeadlessStarter).

Fair, I added it to the the codecocoon.yaml config file, parsed in ConfigLoader and passed as a parameter via the MemoryAwareTransformation's config (it should be injected).

I agree the CLI parameter would be nice for eval, but none of the others are parameterized, so I skipped for now. Maybe we should consider doing it for all configs.

See 18fba0c

❗️MAJOR API Concern about RenameMemory and MemoryAwareTransformation ❗️

This comment addresses some architectural caveats of how memory API is current integrated with transformations.

You don't need this RenameMemory class be rename-specific; in fact, it doesn't need to know what type of information it stores whatsoever.

What you have is a general-purpose interface of any persistent storage, like Redis/Database or even a simple in-memory Map<String, String>.

I suggest turning this API into an interface Memory with a single implementation that stores entries under a filepath given by the caller:

// you only need these 4 methods (maybe you don't even need `size` method)
interface Memory<K, V> {
    fun get(key: K): V?
    // returns the previous value if present, otherwise `null`
    fun put(key: K, value: V): V?
    fun dump(): Unit // or `save`
    fun size(): Int/Long
}

Even better approach is to make it AutoCloseable, since you always need to "save" your memory once you're done with it. Do it as:

interface Memory<K, V> : AutoCloseable {
    // ... as above ...

    fun close() {
     // we kinda know how to close it already:
     this.save() // or this.dump()
    }
}

Given this interface, you write an implementation that stores data on disk:

class PersistentProjectMemory(
   filepath: String, // base directory where to store/from where to load the JSON file with cached entries
   projectName: String,
) : Memory<String, String> {
     // ...
}

This gives you a high level of freedom of how to integrate this memory with transformations; you can:

1. Create a single globally defined Memory instance shared by all transformations (somewhere in the TransformationService or HeadlessStarter).
2. Create a memory instance for every transformation applied (I think this is the approach you currently have with MemoryAwareTransformation).

Next, you can create a memory instance either project-wide or per-transformation in the TransformationService:

// inside `TransformationService`

class TransformationService {

   fun applyTransformations() {

         // ...
         // (1): define a memory instance here -> you get a single memory for an entire project under transformation
         val globalMemory = PersistentProjectMemory(baseDir, projectName)

         for (tr in transformations) {
             // (2): define memory instance here -> you get a per-transformation memory instance
             val memory = PersistentProjectMemory(baseDir, projectName)
             try {
                 executor.execute(tr, context, memory)
             } finally {
                  // IMPORTANT: we successfully "close" the resource, i.e. dump data on disk/save in the db or Redis, etc.
                  memory.close() // aka `memory.save()/memory.dump()`
             }
         }

    }
}

As for the transformations (namely, IntelliJAwareTransformation interface), I'd simply add another parameter memory: Memory into apply method. The transformations that can benefit from memory, will do so; otherwise, it'll be a no-op parameter, which is fine for us.

Problems with MemoryAwareTransformation:

1. It removes the freedom of selecting a scope for your memory (i.e., you always have it per-transformation; you cannot make it project-scoped, or place anywhere else). This is because MemoryAwareTransformation uses inheritance, which in this case is inferior to the compositional approach.
2. It tightly couples transformation and persistent memory.
3. Besides, we spawned quite a lot of transformation-related classes; making it even larger hinders maintainability.

In other words, the main problem with MemoryAwareTransformation is that it uses inheritance and couples memory and transformations way too strongly.

Co-authored this with Claude. The following changes were made in 69c7d6b:

1. Created generic Memory<K,V> interface - implementation-agnostic, supports AutoCloseable
2. Renamed RenameMemory → PersistentMemory
3. Changed from inheritance to composition - memory now passed as parameter to apply(), not managed by base class
4. Global memory scope - TransformationService creates one instance per project via .use {}, automatic save on close
5. Deleted MemoryAwareTransformation - no longer needed

I left an instance running to see if I didn't break anything with the refactoring. I'll report in the morning if there's anything.

Let's move the entire logic into resolveMavenProject function or something. Why do we need it and why does it use some counts and thread sleeps?